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(57) In rin exemplary embodiment, the server re- 
ceives the dent's Distinguishing Name (DN), and then 
searches its directory lor identification information and 
access controJ rights lor this specific context. The server 
can act as h stand-alone server or in conjunction with 
other director,' scrvces on the network. A client must 
have a verifiable identity in order for secure communi- 
cations to continue A client's identity can be said to be 
fully verifiable if tnc server has access to the directory 
service that maintains that client's DN. The client re- 
ceives the server's DN, and the client can then deter- 
mine whether or not to accept a response to a request 
for information (ic . trust the response). The client de- 
termines the identity of the server using some directory 
service (the client can act stand-alone or as a client of 
other directory servers) A server is fully verifiable it the 
client can identity the dnectory service that maintains 
the server's DN. tn both cases, determining identity is 
predicated on being able to identify a directory service. 
Since servers and clients are issued identities (DN's) 
from some directory service before they participate in 
secure communications, they are able to at least identify 
their "home" directory service. Their "home" directory 
service communicates with other directory services, 
each "serving" their lists ol electronic identities to each 
other using secure directory services. In this manner, a 
client or server can verify the peer identity of a secure 
communicator by relying on the trusted "home" directory 
service. Public Key certificates, certificate revocation 



lists, pending certificate requests, Certification Authority 
policy, and other information is stored in the directory 
server Access to the directory server is through secure 
communications; this maintains the integrity and privacy 
of the information. 
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Description 

FIELD OF THE INVENTION 

The invention generally relates to the field of digital 5 
data processing communications systems in which a us- 
er at a workstation requests information or services from 
a server computer More particularly, the invention re- 
lates to a method of and apparatus for providing a public 
key infrastructure via secure directory services within a 
computer system and/or a computer network. 

BACKGROUND AND SUMMARY OF THE 
INVENTION 

With the widespread and ever mushrooming use of 
network-based communications, a business world 
where electronic-based business transactions are the 
rule rather than the exception has been a longstanding 
vision shared by many. A major stumbling block to wide- 
spread electronic business transactions is the need to 
effectively deploy a secure communications system pro- 
viding privacy, message integrity, non-repudiation and 
authenticity. 

Cryptographic systems have been widely used to 
ensure the privacy and authenticity of messages com- 
municated over a wide variety of different networks. 
Many conventional cryptosystems are not satisfactory 
for widespread business world deployment due to well 
recognized problems relating to, for example, key dis- 
tribution. 

Public key cryptographic systems have been ad- 
vantageously utilized to solve existing cryptographic 
system problems including key distribution problems. 
Such public key cryptographic systems use a public key/ 
private key pair and decouple the encrypting and de- 
crypting processes such that the encrypting process key 
is separate and distinct from the decrypting process key. 
In such systems, given the knowledge of the encryption 
key and an encryption key that is large enough, it is not 
viable to compute the decryption key and thus the en- 
cryption key for users may be distributed or published. 
Anyone desiring to communicate with a user at a partic- 
ular destination, encrypts a message under the destina- 
tion user's public key. Only the destination user who re- 
tains the secret decrypting key of the public key/private 
key pair is able to decipher the transmitted messages. 

In public key cryptographic systems, it is known that 
a trusted authority may create a digital message which 
contains a claimant's public key and the name of the 
claimant. A representative of the trusted authority digit- 
ally signs the digital message with the authority's own 
digital signature. Such a digital message, referred to as 
a digital certificate is transmitted along with the use of 
the claimant's own digital signature. See U.S. Patent 
No. 4,405,829 issued to Rivest et al., which discloses 
exemplary methodology for a practical public key cryp- 
tographic system implementation. Also see U.S. Patent 
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No. 5,214,702, which describes a public key digital sig- 
nature cryptographic system having enhanced digital 
signature certification. 

Existing public key cryptography methodologies en- 
vision that electronic business transactions employ a 
global standard for tying the public key use to a high 
level global authority, using what is referred to as the X. 
500 standard. Not all users, however, participate in this 
global standard, thereby limiting the standard's practical 
utility. 

The present methodology does not rely on a global 
standard. In accordance with an exemplary embodi- 
ment of the present invention, cryptographic keys may 
be resident in a user's own directory services, while per- 
mitting users to securely communicate with each other 
as a result of using the distributed directory services de- 
scribed herein. The present invention utilizes secure 
distributed directory services to maintain a public key 
infrastructure, and does not operate in the conventional 
global, top-down hierarchy using a "meta-certifier", who 
must certify all users in order to provide the desired level 
of security. 

In accordance with an exemplary embodiment, us- 
ers may receive digital certificates from various other us- 
ers and still securely communicate with each other with 
sufficient security such that electronic business trans- 
actions may be culminated. The present invention incor- 
porates the use of policy statements which efficiently 
permit trust levels to be applied to a user's service re- 
quest based upon an analysis by the recipient of the 
message sender's identity via the distributed directory 
services system. Thus, the fact that a particular mes- 
sage sender is identified in a given distributed directory 
service using designated policy statements, permits the 
message recipient to determine-the degree of trust to 
be given to a message sender. 

The exemplary embodiment implements the con- 
cept that by being able to uniquely identify a client in a 
specific communications context, a server can assign 
the client with specific access rights for that context. The 
access rights granted to a client depend on the client's 
identity in that context. 

Given that access rights are based on identity, the 
feature of being able to uniquely identify a client be- 
comes significant. The server requires a secure and in- 
fallible method of identifying the client. The infallibte 
method is based on using secure directory services of 
the nature described in the present exemplary embodi- 
ment. By securely receiving identity verification services 
from a directory service, the server can then determine 
the access rights to grant to a client. This allows a server 
to deliver client-sensitive information, without prior 
knowledge of the client. 

In accordance with an exemplary embodiment of 
the present invention, a client initiates a secure connec- 
tion with a server providing directory services. The serv- 
er, taking advantage of the authentication feature in the 
secure communications methodology described herein, 
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uniquely identifies the client and thus obtains the client's 
distinguished name (DN). The server uses the client's 
DN to determine what access rights to grant the client, 
either by looking up the client's DN in its own directory 
or by recursively acting as a client to another directory s 
server that contains definitive information about that 
particular DN. The directory server then returns the in- 
formation to the client that is specific to that client and 
is able to do so by taking advantage of the authentication 
feature provided by the secure communications meth- io 
odology used herein. 

In accordance with another aspect of the present 
invention, a client initiates a secure comRtunication with 
a server. The methodology described herein is also ap- 
plicable to the instance where the client and server are is 
on the same machines so that the network described 
herein may be internal to the computer in this special 
case. The server is able to uniquely identify the client 
based on the authentication feature of the secure com- 
munications server as a directory service to verify the 20 
identity of the client's DN and for access control permis- 
sions to grant to the client This communication with the 
directory service must be over a secure communica- 
tions channel because the information passed on to the 
clientyserver communication depends on the result and 
verification and access rights returned by the directory 
service. The directory service responds to the server 
with verification information and access control informa- 
tion, particular to that client and the server is able to de- 
termine what information should be sent to the client. 
The server then returns either none, some or all the in- 
formation requested by the client. 

In an illustrative embodiment, the identities of the 
parties involved determine the access rights for a direc- 
tory service's communications context. All requests for 
information made by the client, receive customized di- 
rectory service responses. The peer identities are de- 
termined through the use of secure communications. 

In an exemplary embodiment, the server receives 
the client's Distinguishing Name (DN), and then search- 
es its directory for identification information and access 
control rights for this specific context. The server can 
act as a stand-alone server or in conjunction with other 
directory services on the network. A client must have a 
verifiable identity in order for secure communications to 
continue. A client's identity can be said to be fully veri- 
fiable if the server has access to the directory service 
that maintains that client's DN. 

The client receives the server's DN, and the client 
can then determine whether or not to accept a response 
to a request for information (i.e. , trust the response) . The 
client determines the identity of the server using some 
directory service (the client can act stand-alone or as a 
client of other directory servers). A server is fully verifi- 
able if the client can identify the directory service that 
maintains the server's DN. 

In both cases, determining identity is predicated on 
being able to identify a directory service. Since servers 



and clients are issued identities (DN's) from some direc- 
tory service before they participate in secure communi- 
cations, they are able to at least identify their "home" 
directory service. Their "home" directory service com- 
municates with other directory services, each "serving" 
their lists of electronic identities to each other using se- 
cure directory services. In this manner, a client or server 
can verify the peer identity of a secure communicator by 
relying on the trusted "home" directory service. 

The present exemplary implementation of the in- 
vention can be used to implement a Public Key Infra- 
structure in the following manner Public Key certifi- 
cates, certificate revocation lists, pending certificate re- 
quests, Certification Authority policy, and other informa- 
tion is stored in the directory server. Access to the di- 
rectory server is through secure communications; this 
maintains the integrity and privacy of the information. 
Administrators acting in the capacity of the Certification 
Authority are granted full access to the repository, by 
issuing them the "Administrator's DN", and can add new 
certificates, modify certificate revocation lists, etc. Oth- 
ers would have less access, to the limit that unknown 
parties may only be allowed to submit certificate re- 
quests or download public certificates (and revocation 
lists). Additionally, certificates can be used as vectors in 
directory searches; the client attempting the directory 
search has its access limited by its client DN, and the 
client's DN may not contain a name at all, but rather a 
hash of the client's policy. In this manner, certificates can 
be issued that contain minimal information; in fact, they 
only need to contain a unique identifier that can be used 
as a vector in the vector space (this would be the entire 
namespace that is visible to that particular client). 

BRIEF DESCRIPTION OF THE-DRAWINGS 

These as well as other features of this invention will 
be better appreciated by reading the following descrip- 
tion of the preferred embodiment of the present inven- 
tion, taken into conjunction with the accompanying 
drawings of which: 

FIGURE 1 is a block diagram of an exemplary com- 
munications system within which the present inven- 
tion may be utilized; 

FIGURE 2 is a data flow diagram showing illustra- 
tive data communicated between a directory client 
and a server; 

FIGURE 3 is a data flow diagram exemplifying how 
a client may be identified in a secure communica- 
tions protocol; 

FIGURE 4 is an example of a digital certificate 
which may be used in conjunction with FIGURE 3; 

FIGURE 5 is a flowchart of the general sequence 
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of operations performed in accordance with an ex- 
emplary embodiment; 

FIGURES 6A and 6B are a flowchart delineating an 
exemplary sequence of operations involved in the 
identification verification process; 

FIGURE 7 is an exemplary verification descriptor 
object/data structure; 

FIGURE 8 is an exemplary context descriptor ob- 
ject/data structure; 

FIGURE 9 is an exemplary data structure/object uti- 
lized in conjunction with FIGURE 6A, block 80, ver- 
ification analysis; 

FIGURE 10 is an exemplary object data structure 
used in performing verification analysis of FIGURE 
6A, block 86. 

FIGURE 11 is an exemplary object used in perform- 
ing the verification analysis of FIGURE 6A, block 

90. 

FIGUFtE '2 ts an oxomplary object/data structure 
used lor retrieving an hccoss control list rule; 

FIGURF 1 *\ nn across list control rule object/data 
structure? 

DETAILED DESCRIPTION OF AN EXEMPLARY 
EMBODIMENT OF THE INVENTION 

Figure 1 shows m block diagramform, an exemplary 
computing system within which the present invention 
may be utilized ns part ol an electronic commerce/com- 
munications not work It should be recognized that, while 
the present methodology may be utilized in such a com- 
munications network environment, the invention may 
likewise be used in conjunction with a wide range of data 
processing systems, including one or more laptop com- 
puters, stand-alone. PC-type computers, minicomput- 
ers, and any other computer system environment where 
data security is a signilicant concern and practically im- 
plementable. 

Before describing an exemplary communications 
system, which may be used in conjunction with the 
present invention, terminology utilized herein is first de- 
scribed. A "client process" or program runs on a com- 
puter attached to a network. The client process is dis- 
tinguished by the fact that it makes requests for infor- 
mation or services. The client process may be referred 
to herein as a client. 

A "server process" also runs on a computer at- 
tached to a network. The server process is distinguished 
by the fact that it fulfills requests for information or serv- 
ices. The server process may be referred to herein as 



a server. It should be recognized that a client and a serv- 
er may actually run on the same computer and that a 
server may be a client to another server. 

As used herein, "secure communications" typically 

5 refers to any data transport mechanism, which prefera- 
bly provides, but is not limited to, privacy, message in- 
tegrity, non-repudiation, and authenticity. 

A "Distinguished Name" (DN) uniquely identifies an 
entity participating in a digital conversation preferably 
enabled via secure communications. 

A "communications context 1 is an instance where a 
client is requesting information from some server, and 
the request for information can be distinguished by one 
or more of the following: client DN, server DN, informa- 

15 tion requested, information available, and access con- 
trols on that information. 

Turning back to Figure 1 , this figure shows an ex- 
emplary communications network including multiple cli- 
ent computing devices, and combination client/server 

20 computing services interconnected via local networks, 
and through an Internet. The local area networks (LANs) 
shown in Figure 1 , i.e., LAN 1 and LAN 1 3 are depicted 
for illustration purposes only. These networks are in- 
tended to be representative of any of the many network 

25 designs, such as Ethernet, token ring, or other type of 
networks having attached clients and servers which are 
likewise intended to be subsumed by the Figure 1 archi- 
tecture. By way of example only, LAN 1 may be an Ether- 
net 802.3 10 base T network. A variety of protocols run 

30 on LAN 1 , including TCP/IP and NETBIOS. Although nu- 
merous protocols may be running on LAN 1, TCP/IP is 
preferably utilized, which is the protocol that runs on the 
Internet. 

As shown in Figure 1, LAN 1 includes a PC-type 

35 computer 2 operating solely as a client, which may, for 
example, be a Windows 95-based workstation. LAN 1 
additionally includes a workstation 3 which may, for ex- 
ample, be an IBM RS 6000, operating as both a client 
and a server. The IBM RS 6000 typically runs the AIX 

40 operating system. Client/server 3 may be running as a 
client in the context of the methodology described herein 
and/or as a server having its own X.500 directory space. 

LAN 1 also includes a minicomputer server 4, which 
may be any commercially available minicomputer. Min- 

45 icomputer server 4 may, for example : be dedicated to 
providing digital certificates or directory services. Mini- 
computer server 4 may be attached to another network 
(not shown). As suggested by inclusion of minicomputer 
server 4, servers are not limited to workstation type de- 

50 vices. 

LAN 1 may, for example, also include a graphics- 
based SGI client/server 6, which may be one of the 
workstations manufactured by Silicon Graphics Corpo- 
ration. Client/server 6 may perform computer graphics 
55 and/or CAD operations. Workstation client 8 may, for ex- 
ample, be an IBM PC-based work station and is repre- 
sentative of the numerous additional available worksta- 
tions which may, if desired, be coupled to LAN 1 . 
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The secure communications with directory services 
of the present invention occur not only on the exemplary 
LAN 1 , but also on LAN 1 3. LAN 1 3 also runs protocols 
including TCP/IP for Internet communication. 

LANs 1 and 13 may, for example, communicate via 
the Internet 22, via routers 16 and 18. Routers 16 and 
18 are conventional routing computers for Internet com- 
munications, having sufficient memory capacity to per- 
form necessary routing functions and keep track of the 
devices with which they are associated on the Internet. 
A router provides a quick connection between two de- 
vices on the Internet. A router 16,18 may serve more 
than one LAN. The routers 16 and 18 may, fqi sample, 
be routers commercially available from Cisco Corpora- 
tion. 

Various other clients such as Smart Card Reader 
20 and laptop client 24 may be attached to, and com- 
municate with, any of the other depicted devices through 
the Internet via phone lines 23,25. Smart Card Reader 
20 may, for example, be a Visa card reader. With respect 
to Smart Card Reader 20, although the concept of a "cli- 
ent" described thus far has been applied to a program 
requesting information or services, a client may also be 
hardware or circuitry embodied in, for example, a Smart 
Card Reader requesting information or services. 

LAN 13 includes a client/server 12, which may, for 
example, be a SUN Microsystems SPARC, which is a 
RISC -based workstation. LAN 1 3 also includes a client 
workstation 10 which may be a Mac II, manufactured by 
Apple Corporation, and a client/server 14, which may 
be a DEC workstation. Workstations 10, 12 and 14 are 
exomplary workstations which may be coupled to a LAN 
each of which may be running different operating sys- 
tems 

Although the LANs 1 and 13 are coupled together 
via the Internet 22, the method and apparatus may be 
advantageously utilized without Internet connections. 
Thus, for example, an intraoffice network may distribute 
digital certificates and secure information in accordance 
with the present invention. It should be understood that 
the present invention may be employed with any subset 
of the structure shown in Figure 1 . 

Figure 2 is a data flow diagram showing illustrative 
data communicated between directory client 40 and 
server 42, in accordance with an exemplary embodi- 
ment of the present invention. The directory client 40 
may be, for example, any of the enumerated clients pre- 
viously described above in conjunction with Figure 1 . 
Similarly, server 42 may be, for example, any of the serv- 
ers identified above in Figure 1 . The directory server 44, 
the secure communications protocol component 46 s the 
directory access component 48, and the internal direc- 
tory database 50 are resident in server computing de- 
vice 42. As set forth above, directory client 40 requests 
information or services from a server 42. Client 40 is 
identified as a directory client and is therefore seeking 
directory information. The directory itself may be distrib- 
uted and reside virtually anywhere in the Figure 1 net- 



work. The directory stores information regarding individ- 
ual users and corporate entities such as, for example, 
may be contained in a white page directory. For exam- 
ple, the directory may include client data including a Dis- 
5 tinguished Name or another unique client identifier. In 
addition to the client identifier, a directory may store pub- 
lic key information for identifying the public key of the 
party to which it is desired to securely communicate. Di- 
rectory Server 44 within server 42 operates in accord- 

10 ance with a preestablished directory protocol to serve 
directory information to directory clients. If the directory 
server 42, by accessing its associated internal data 
base 50, can adequately respond to the client's directory 
related query, server 42 appropriately responds. If not, 

'5 the question may be responded to by server 44 by re- 
turning a referral to directory client 40 to identify the lo- 
cation of a server which can respond. Alternatively, di- 
rectory server 44 may be chained to other directory serv- 
ers and may attempt to find the answer to the inquiry, 

20 rather than sending a referral to directory client 40. In 
this context, the directory server 44 operates as a client 
to another directory server. 

The secure communications protocol component 
46 ensures that the directory client 40 communicates 

25 with directory server 44 using a secure communications 
protocol. The secure communications protocol prefera- 
bly provides privacy, authentication, non-repudiation, 
and integrity to the communications between client 40 
and server 42. In conventional systems, no response is 

30 provided when a client is not entitled to access a server. 
In accordance with the present invention, a response 
may be obtained from a directory server which indicates 
whether the client 40 has enough privilege to get the 
requested information as will be described further be- 

35 low. - 

The directory access component 48 of server 42 
permits communication with the server's internal data- 
base 50. The server 42 determines via the direct access 
component 48, what type of access the client 40 is en- 

40 titled to have. 

In operation, in accordance with step 2a, server 42 
receives the client identity from the directory client 40 
using the underlying secure communications protocol. 
Because the communications protocol provides authen- 

45 ticity assurance, the client is securely identified so that 
the server receives a known identity which can later be 
verified. 

Figures 3 and 4 show an example of how a client 
may be identified using a secure communications pro- 

50 tocol. As exemplified in Figure 3, client 60 initiates com- 
munication with server 62 by opening up a network con- 
nection to the server. The precise matter of initiation will 
depend on the nature of the network. Server 62 re- 
sponds to- the connection and demands that client 60 

55 identify itself. Client 60 then sends its identity for this 
communication session in the form of a digital certificate 
to server 62. By way of example only, the secure com- 
munications protocol utilized may be the commercially 
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available SSL protocol, which in accordance with the 
present invention is advantageously applied to directory 
services to provide a secure directory services system. 

Figure 4 is an example of a digital certificate 64 
which may be used to identify the client as described in 
conjunction with Figure 3 above. The digital certificate 
may be, but is not required to be, structured as recom- 
mended in the X.509 standard. The certificate may be 
custom designed to include numerous different and/or 
additional fields as desired. The certificate may be writ- 
ten, for example, in ASN.1 syntax. The digital certificate 
64 includes a "certificate 0 field which is a digitally signed 
sequence, that includes a hash of the data identified be- 
low, which is then encrypted with the signing party's pri- 
vate key. Within the information that is digitally signed 
is a version number, a serial number which uniquely 
identifies the certificate, and the signature of the signing 
party in accordance with an identified algorithm such as 
RSA. Additionally included within the signed certificate 
information is an identification of the certificate issuer, 
identifying the name of the party that signed the digital 
certificate. The certificate includes a validity field which 
specifies how long the certificate is valid. The subject 
field specifies the name of the party who holds the cer- 
tificate, and the public key information field specifies the 
public key of the subject. The fields referred to above 
are expanded in Figure 4 to show their constituent con- 
struction in more detail. Figure 4 thus shows an exem- 
plary data structure of a digital certificate which may be 
used in conjunction with the present invention. 

Turning to back to Figure 2, in accordance with step 
2b, the server 42 checks if the client identity is recog- 
nized by the internal directory data base. Thus, if direc- 
tory client 40 transmits client identity information in the 
form of a digital certificate, such as that shown in Figure 
4, server 42 checks the digital certificate to confirm rec- 
ognition from its internal data base 50. The server 42 
initially checks the digital certificate to confirm that the 
signature of the issuer matches the signer's signature. 
Thus, if the internal directory data base 50 has no infor- 
mation regarding the certificate's signer, the client will 
not be identifiable. Under such circumstances, the serv- 
er 42 may act as a client to retrieve the required signer's 
public key information from another server to complete 
the identification. Details of this process are described 
in further detail in conjunction with Figure 6 and subse- 
quent figures described below. 

Once the identity of the client is verified, the internal 
directory returns an access control rule to apply to the 
client's communication session. Alternatively, it may re- 
turn an access denied in the case of an untrusted client. 
Once the client's identity is confirmed, an access control 
list is accessed to retrieve the access rules that apply to 
the communications session. This information is re- 
turned to the directory service protocol 46 via the direc- 
tory access computer 48. 

With respect to step 2d, the communications ses- 
sion is established with the client and the retrieved ac- 



cess control rules are applied to the communications 
session. In this fashion, a client may be precluded from 
retrieving directory information that it is not entitled to 
retrieve, as specified by access control rules. While Fig- 
s ure 2 shows the communication between a directory cli- 
ent 40 and a directory server 42, the methodology is in- 
tended to be applied to a client and server. For example, 
the server may act to retrieve access control rules for 
clients going to its web site. 

Figure 5 shows in flowchart form a general se- 
quence of operations performed in accordance with an 
exemplary embodiment of the present invention. As in- 
dicated in Figure 5, initially the client sends its Distin- 
guished Name (DN) which uniquely identifies the client 
(70). Thereafter, the server receives the distinguished 
name DN (72). 

As suggested by block 74, the server analyzes the 
client DN to determine the appropriate ACL access con- 
trol rules to apply. As indicated by the "recursive" par- 
enthetical in block 74, the server may access other di- 
rectory servers throughout the Internet in order to deter- 
mine the appropriate access rules to apply. In addition 
to access control rules, degree of trust related informa- 
tion which may be associated with the client also may 
be accessed from different servers on the Internet. The 
server, by making requests to other directory servers on 
the Internet, itself becomes the client in its effort to pro- 
vide the access control and trust rules to apply to the 
client. Thus, in the context of a web site, if a client sends 
its distinguished name DN (or an alternative identifier) 
to a web site, the web site needs to identify the client 
either at an internal data base at its associated server 
or at other web sites. The web site can then seek iden- 
tifying information from other directory server web sites 
until a trust relationship with the requesting client is de- 
termined. With such information retrieved from other di- 
rectory servers, the degree of trust which may be asso- 
ciated with the requesting client may be determined. 

If the client is verified in block 74 processing, ACL 
information is returned to the directory server as indicat- 
ed in block 76 and is applied to the data connection. The 
access control rules and trust related information are ap- 
plied to the data connection to ensure that actions take 
place during the data connection in accordance with the 
access control rules and/or the trust information, to 
thereby ensure that authorization levels are not exceed- 
ed. 

In accordance with this methodology, for example, 
a digital certificate possessed by a party which has been 
issued by Visa may be transmitted to a web site and an 
electronic transaction may take place, whereby goods 
are purchased. The transaction may be completed in ac- 
cordance with the client's credit rating which may be 
checked, for example, through Visa's directory server. 
The Visa directory server may determine the nature of 
the credit rating to transmit depending upon the partic- 
ular context, e.g., the party at the web site requesting 
the information and the individual client. During this 
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process, the web site would likewise be transmitting to 
the Visa directory server its digital certificate so that the 
Visa directory server can determine whether the web 
site is, for example, a business which has recently gone 
bankrupt, or another bank which should be associated 
with a great deal of trust. In this fashion, the present in- 
vention enables the transaction parameters to be fully 
developed in the particular communications or business 
transaction context. 

In accordance with Figure 5 at block 78, having ob- 
tained the appropriate access control list rules and/or 
trust information, such information is applied to the data 
connection. The data requested is transmitted back to 
the client, as shown in Figure 5, although the access 
control rule or trust level information would not be com- 
municated. The process may be repeated in connection 
with different subsequent communication sessions. 

Figures 6 A and 6B are a flowchart delineating the 
sequence of operations involved in an exemplary iden- 
tification verification analysis. The input data to the di- 
rectory server verification analysis component is the cli- 
ent identity which may include the digital certificate as, 
for example, shown in Figure 4, communications con- 
text information which is a context descriptor that de- 
scribes the nature and/or type of communication and a 
server identity which is the server's digital certificate. 
The directory server verification analysis flowchart 
shown in Figures 6 A and 6B is implemented by software 
embodied within the directory server 42 shown in Figure 
2. 

Figure 7 is an exemplary verification descriptor ob- 
ject and Figure 8 is an exemplary context descriptor data 
structure utilized in the verification analysis shown in 
Figure 6. Turning first to the verification descriptor, the 
data structure/object shown in Figure 7 includes a digital 
certificate identifying the client and a digital certificate 
identifying the server as well as a context descriptor. In 
the case of a null context descriptor, the context defaults 
to that of the directory server protocol. Thus, if there is 
no context descriptor, the context is presumed to be a 
communication session between a client communicat- 
ing with a directory server. Alternatively, if a web client 
is communicating with a web server and the web server 
is performing a verification analysis, then the context de- 
scriptor is set to indicate a web server communicating 
with a web client. In the case of a null server identity the 
server defaults to the directory server itself. If commu- 
nication takes place between a web client and a web 
server, the web server inputs its web identity via its dig- 
ital certificate. 

As shown in Figure 8, the illustrative context de- 
scriptor includes a version number field and a time field 
which indicates the coordinated universal time. The 
"protocol" field varies depending upon the particular 
communications context. For example, if a web server 
is communicating with a web client, the protocol may be 
the web protocol "http". If an E-mail client is communi- 
cating with an E-mail server, then the protocol may be 



the "SMTP" protocol. Additionally, any parameters de- 
fined by the protocol may be listed in the context de- 
scriptor. 

Turning back to Figure 6A, block 80, the directory 
5 server checks that the digital certificate issuer's public 
key is available to the directory server. For example, if 
Visa issued a digital certificate to a requesting party, a 
check is made at, for example, a web site to determine 
whether the web site can identify Visa and has access 
10 to Visa's public key. If the certificate issuer is known, 
then the digital signature of the certificate issuer may be 
verified. 

Based upon the block 80 analysis, a determination 
is made as to whether the certificate issuer is knownF - 
is (82). If the certificate issuer is no¥T5hown, then the di- 
rectory acts as a directory client to attempt to find a 
known certificate issuer. 

After the directory server acts as a directory client 
to find a known certificate issuer, a check is made at 
20 Figure 6B, block 84 : to determine whether a known cer- 
tificate issuer has been found If so, the routine branches 
back to block 80, and the routine continues. If no known 
certificate issuer is found, then access is denied. 

An exemplary data structure or object utilized in 
2S conjunction with the block 80 analysis is shown in Figure 
9. As shown in Figure 9, the certificate issuer's name is 
identified by using the verification descriptor's client 
identity and the issuer's identity information. As shown 
in Figure 9, the verification process utilizes the issuer's 
30 public key and verification algorithm identifier informa- 
tion. If the data structure shown in Figure 9 has a null or 
blank "issuer public key" field, resolving the unknown 
certificate issuer may involve either storing information 
from another directory in a local cache, acting as a di- 
ss rectory service client to another directory service, or per- 
mitting an unknown signature by deferring resolution un- 
til the access control rules are searched. By permitting 
an unknown signature to be utilized, the system may ac- 
cept the unknown signature, while relying on the access 
40 control rules to determine whether this is appropriate. 
For example, certain web sites may not care who the 
certificate issuer is and, in fact, wish to promote the web 
site to be accessed. Under these circumstances, the ac- 
cessible control list rules may include specific restric- 
ts tions identifying the context where an unknown certifi- 
cate issuer is involved. 

Turning back to Figure 6A, if the certificate issuer's 
public key is available, the directory services verifies at 
block 86 the digital signature, such that the digital sig- 
50 nature on the issuer's certificate matches the internally 
stored public key of the certificate issuer. 

Figure 10 shows an example of an object or data 
structure required to perform the verification operations 
of Figure 6A, block 86. As shown in Figure 10, the client 
ss identity is used which consists of the signed sequence 
embodied in a digital certificate previously discussed in 
conjunction with Figure 4. The issuer's public key is also 
used which includes the information shown, including 
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an algorithm identifier. Thus, the client identity, which is 
a signed sequence defined by a digital certificate, per- 
mits the signature to be verified with the issuer's public 
key. 

A check is next made at Figure 6A, block 88 to de- 
termine whether the signature is good. If the signature 
is bad, then as shown in Figure 6B t access is denied or, 
as previously described, a decision may be made to de- 
fer resolving this issue until the access control rules are 
checked. 

If the check in block 88 indicates that the signature 
is good, then, as indicated in block 90, the directory serv- 
ice vaMfies that the certificate is still currently valid by 
checking an internally stored certificate status or option- 
ally, a check is made of an internally stored certificate 
revocation list. 

Figure 11 shows exemplary objects or data struc- 
tures which may be used in performing the verification 
indicated at Figure 6A, block 90. As shown in Figure 11 , 
the client identity information includes the digital certifi- 
cate previously discussed. The certificate revocation list 
is a list of certificates which have been previously re- 
voked and may be presented as attributes with an^at- 
tnbute-syntax certificate list. The list would be in the 
form of a signed sequence of certificates as shown in 
Figure 1 1 . The signed sequence includes the certificate 
serial numbers and the revocation date. The certificate 
revocation list would be prepared by the controlling di- 
rectory service entity. If the certificate serial number 
identifying a client is stored in a certificate revocation list 
kept at a directory service and the certificate is revoked, 
the certificate revocation list may only be modified by 
those who are properly authorized. The revocation list 
may bo prepared and revised by an authority connecting 
to the directory service having more expansive rights 
than the typical client. Such authority would include the 
authority to write into such data structures as the certif- 
icate revocation list. Such a connection would typically 
take place only with the directory service administrator's 
digital certificate. The directory service may not need to 
maintain a full certificate revocation list since it may be 
constructed from the raw data stored in the directory 
service. Thus, information may be stored in the directory 
service indicating that a particular certificate is not valid. 
Raw data stored in the directory service permits per cer- 
tificate lookups for validity purposes. The certificate rev- 
ocation list may be retrieved from a local cache, from 
another directory service or deferred until the ACL rule 
check. 

Turning back to Figure 6A, based on the processing 
in block 90, a check is made to determine if there is a 
valid certificate (92). If there is not a valid certificate, as 
determined by the check in block 92, then connection is 
denied or deferred as previously described. 

If there is a valid certificate, then, in accordance with 
block 94 processing, the directory cross-references the 
client certificate, the server certificate and the commu- 
nications context to retrieve an internally stored access 



control rule to apply to the client connection. 

Figure 1 2 discloses an exemplary object or data 
structure which may be used for the block 94, Figure 6 
processing, for retrieving an access control rule, an ex- 
s ample of which is shown in Figure 13. The set of access 
control rules are defined in the directory service data- 
base. Various directory servers may be linked so that 
access control rules stored in other directory servers 
may be utilized and may be required in order to fully de- 
10 termine the access control rules that apply. The directo- 
ry servers may be linked based upon prearranged con- 
tractual trust relationships. For example, a trust relation- 
ship with a Visa card may require that visa trust a given 
merchant and its cardholder, and that the merchant trust 
*s the Visa cardholder. The ACL rule is accessed by the 
server itself by use of the context and the client certifi- 
cate and the server's certificate. An ACL rule is retrieved 
from the server's internal database, based on the client 
identity, the context descriptor (which may, for example, 
indicate whether E-mail or a web site related transaction 
is involved), and the server identity. 

As shown in Figure 13, the ACL rule is a digital se- 
quence including a "to what" field, which, for example, 
may indicate that the rule applies to a web page. An ACL 
rule may also include parameters associated with the 
"to what" field which may for example, include a web 
page address or a credit card number, the nature of the 
card and/or the cardholder's name. A "by what" field may 
also be included, which typically includes the client's 
certificate, which may be identified by a client ID. "By 
what" parameters are included which may be, for exam- 
ple, a digital certificate. An "access" field may also be 
included and is comprised of an integer defining the al- 
lowable directory access modes. By way of an example 
access integers 0-4 may respectively indicate search, 
compare, read, write or none. The access control rule 
may also include a version number. 

If the certificate issuer's signature or the certificate 
revocation list checking operations were deferred until 
Figure 6A, block 94 processing, then these events are 
passed on as part of the context field shown in Figure 
12. Additionally, the certificate revocation list can be part 
of an access control rule list in the deferred case. Addi- 
tionally, it is noted that trust levels can be defined in an 
access control list rule. The access control rules may be 
retrieved from a local cache memory, or from another 
directory service. Limits may be placed on any particular 
limitation as to when access control rules must be kept 
local or when they may be retrieved from another direc- 
tory service. 

Turning back to Figure 6A, the access control rule 
is applied to the data connection so that the client only 
receives the correct and intended data. The verification 
component thus returns an access rule to be applied for 
the client to the server. 

While the invention has been described in connec- 
tion with what is presently considered to be the most 
practical and preferred embodiment, ft is to be under- 
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stood that the invention is not to be limited to the dis- 
closed embodiment, but on the contrary, is intended to 
cover various modifications and equivalent arrange- 
ments included within the spirit and scope of the ap- 
pended claims. s 



Claims 

1 . A method for providing secure communications be- 10 
tween a client at a first workstation and a computer 
comprising the steps of: 

receiving at said computer a request from said 
client for at least one of information and servic- is 
es : said request including at least one digital 
certificate identifying said client; 
checking at said computer to determine if the 
issuer of said digital certificate is recognised; 
verifying that said digital certificate is valid; and 20 
retrieving, if the digital certificate is valid, an ac- 
cess control rule to apply to the communication 
session with said client during which at least 
one of information and services is provided to 
said client. 25 

2. A method for providing secure communications be- 
tween a client at a first workstation and a computer 
comprising the steps of: 

30 

receiving at said computer a request from said 
client for at least one of information and servic- 
es, said request uniquely identifying said client; 
checking at said computer to determine if the 
client is recognised by said computer; 35 
retrieving, if the client is recognised, an access 
control rule to apply to the communication ses- 
sion with said client during which at least one 
of information and services is provided to said 
client; 40 
applying said access control rule to the com- 
munications session with said client. 

3. A method for providing secure communications be- 
tween a client at a first workstation and a computer 45 
comprising the steps of: 

receiving at said computer a request from said 
client of at least one of information and servic- 
es, said request including at least one digital so 
certificate identifying said client; 
checking at said computer to determine if the 
digital signature in said digital certificate is val- 
id; and 

retrieving an access control rule to apply to the ss 
communication session with said client during 
which at least one of information and services 
is provided to said client. 



4. A method according to any one of claims 1 to 3, 
wherein said computer includes an internal data 
base and wherein said step of checking includes the 
step of checking to determine if the public key of an 
identified certified party is stored in said internal da- 
ta base. 

5. A method for providing secure communications be- 
tween a client at a first workstation coupled to a net- 
work including a plurality of computers comprising 
the steps of: 

receiving at a first computer a request,/ rom said 
client for at least one of information anci servic- 
es, said request uniquely identifying said client; 
checking at said first computer to determine if 
the client is recognised; 
checking at a second computer coupled to said 
network, to determine if the client is recognised; 
and 

retrieving from said second computer, if the cli- 
ent is recognised, an access control rule to ap- 
ply to the communication session with sard cli- 
ent during which at least one of information and 
services is provided to said client. 

6. A method according to any one of claims 1 , 3, or 5, 
further including the step of applying said access 
control rule to the communications session with 
said client. 

7. A method according to claim 5, further including the 
step of identifying a second computer for operating 
as a server which can verify the identity of said client 
and interconnecting said second computer with 
said first computer via the Internet. 

8. A method according to any one of claims 1 , 3, 4, or 
5, further including the step of accessing informa- 
tion related to the degree of trust which may be as- 
sociated with said client. 

9. A method according to claim 2 or claim 5, wherein 
said receiving step includes the step of uniquely 
identifying the client via a digital certificate. 

10. A method according to claim 2 or claim 5, wherein 
said receiving step includes the step of receiving 
data uniquely identifying the client including the cli- 
ent's public key. 

11. A method according to claim 5, wherein said first 
computer and said second computer include an in- 
ternal data base and wherein said step of checking 
includes the step of checking to determine if the 
public key ol an identified certifying part is stored in 
said internal data base. 
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12. A method according to any one of claims 1 , 2, 3, or 
6, wherein said computer includes a directory and 
wherein said step of applying said access control 
rules includes the step of permitting the client to ac- 
cess said directory only in accordance with said ac- 
cess control rules. 

13. A method according to any one of claims 1 , 2, 3, or 
6, wherein said client requests access to a web site 
via said request and wherein said step of applying 
said access control rules includes the step of per- 
mitting the client to perform operations at said web 
site only in accordance with said access control; 
rules. 

14. A method according to any one of claims 1 , 3, or 9, 
further including the step of accessing information 
related to the degree of trust which may be associ- 
ated with said client. 

15. A method for providing secure directory services 
communications between a client at a first worksta- 
tion and a computer comprising the steps of: 

transmitting from a client's workstation a re- 
quest fordirectory services to said computer for 
at least one of information and services, said 
request including digital information for unique- 
ly establishing that said client has a known 
identity which can subsequently be unambigu- 
ously verified; 

checking to determine if the client is recognised 
by said computer; 

retrieving an access control rule to apply to the 
communication session with said client during 
which directory services is provided to said cli- 
ent; and 

applying said access control rule to the com- 
munications session with said client. 

1 6. A method for providing secure communications be- 
tween a client at a first workstation coupled to a net- 
work including a plurality of computers, each of said 
plurality of computer including a directory server 
and an associated data base, comprising the steps 
of: 

transmitting from said first workstation to a first 
computer of said plurality of computers a re- 
quest from said user for at least one of informa- 
tion and services, said request uniquely identi- 
fying said client; 

checking by the first computer's directory serv- 
er, the associated data base at said first com- 
puter to determine if the client is recognised by 
said first computer; 

checking by the second computer's directory 
server, the associated data base at said second 



computer coupled to said network, to determine 
if the client is recognised; and 
retrieving from said second computer, if the cli- 
ent is recognised, an access control rule to ap- 
5 ply to the communication session with said cli- 

ent during which at least one of information and 
services is provided to said client. 

17. A method according to claim 16, further including 
10 the step of accessing trust related information from 
the internal data base of said second computer. 

- ^.j 18- A method according to claim 17, further including 
the step of applying the trust related information and 
*s the access control rule to the client's request to en- 
sure that authorisation levels are not exceeded. 

19. A method according to claim 17, wherein said re- 
quest is a request for an electronic business trans- 

20 action transmitted to a web site. 

20. A method according to claim 17 : wherein the re- 
quest is a request for a business transaction and 
wherein the server which recognises the client de- 

25 velops transaction parameters in the context of the 
parties involved. 

21. A method according to claim 17, wherein said trans- 
mitting step includes the step of uniquely identifying 

30 the client via a digital certificate. 

22. A method according to claim 17, wherein said trans- 
mitting includes the step of transmitting data 
uniquely identifying the client including the client's 

35 public key. - 

23. A method according to claim 17, wherein said step 
of checking by said first computer's directory server 
includes the step of checking to determine if the 

40 public key of an identified certifying part is stored in 
said associated internal data base. 

24. A method according to claim 17, further including 
the step of applying said access control rules to per- 

45 m it the client to access said directory only in accord- 
ance with said access control rules. 

25. A method according to claim 17, wherein said client 
requests access to a web site via said request and 

50 further including the step of applying said access 
control rules to permit the client to perform opera- 
tions at said web site only in accoredance with said 
access control rules. 

55 26. A method for providing secure directory services 
communications between a client at a first worksta- 
tion and a computer having a directory server com- 
prising the steps of: 
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transmitting from a client's workstation a re- 
quest tor directory services to said computer 
said request from said client including at least 
one of information and services, said request 
including a digital certificate for uniquely estab- s 
lishing that said client has a known identity 
which can subsequently be unambiguously 
verified; 

verifying by said directory server the authorisa- 
tion for the server to comply with the request 10 
based upon at least one digital certificate and 
information related to the request context; and 
retrieving an access control rule to apply to the 
communication sessbn with said client during 
which directly services is provided to said cli- is 
ent. 



27. A method according to claim 26, further including 
the step of applying said access control rule to the 
communications session with said client. 

28. A method according to claim 26, wherein said re- 
quest includes the client's public key. 

29. A method according to claim 26, wherein said com- 
puter includes an internal data base and wherein 
said step of verifying includes the step of checking 
to determine if the public key of an identified certi- 
fying party is stored in said internal data base. 

30. A method according to claim 27, wherein said com- 
puter includes a directory and wherein said step of 
applying said access control rules includes the step 
of permitting the client to access said directory only 
in accordance with said access control rules. 

31 . A method according to claim 27 : wherein said client 
requests access to a web site via said request and 
wherein said step of applying said access control 
rules includes the step of permitting the client to per- 
form operations at said web site only in accordance 
with said access control rules. 

32. A method according to claim 1 5 or claim 26, further 
including the step of accessing information related 
to the degree of trust which may be associated with 
said client. 

33. Apparatus for providing secure directory services 
while responding to a request for information or 
services by a client at a first workstation comprising: 

a secure communications input module for re- 
ceiving from said client's workstation a request 
for directory services including at least one of 
information and services, said request includ- 
ing a digital certificate for uniquely establishing 
that said client has a known identity which can 



subsequently be unambiguously verified; 
a directory server module for responding to said 
request; and 

a database for storing information indicative of 
the public key of the issuer of the client's digital 
certificate and for storing access control rules 
to apply to requests; 

said directory server module being operable to 
verify the authorisation for the server to comply 
with the request based upon at least one digital 
certificate and information related to the re- 
quest context and for retrieving an access con- 
trol rule to apply to the communication session 
with said client during which directory services 
are provided to said client. 

34. Apparatus according to claim 33, wherein said di- 
rectory server module to operable to apply said ac- 
cess control rule is applied to the communications 
20 session with said client. 
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Fig. 3 



**T 

v 3a Client initiates communications 
by opening up a network connection 
to the server 




— 7 : ► 

v 3b Server responds to connection, 
and demands identification 


Client 




s 3c Client sends identity for this session, 
in the form of a digital certificate. 
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Certificate 



version 



serialNumber 
signature 
issuer 
validity 
subject 

SubjectPublicKeylnfo 

Version 
SerialNumber 
Validity 

notBefore 

notAfter 
SubjectPublicKeylnfo 

algorithm 

subjectKey 
Algorithmidentifier ::= 

algorithm 

parameters 



::= SIGNED SEQUENCE { 

[OJVersion DEFAULT 1988, 



SerialNumber, 
Algorithmidentifier 
Name 
Validity, 
Name, 

SubjectPublicKeylnfo} 
INTEGER ( 1988(0)} 
INTEGER 
SEQUENCE { 
UTCTime, 
UTCTimej 
::= SEQUENCE { 

Algorithmidentifier 
BIT STRING) 
SEQUENCE { 

OBJECT IDENTIFIER 
ANY DEFINED BY algorithm 
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FROM 
FIG. 5 



Client identity (digital certificate), 
Communications Context (context 
descriptor), and Server Identity 
(digital certificate) 



Fig. 6 A 



-TO 

1FIG.6B 



The directory service checks that the digital certificate 
issuer's public key is available to the directory service 
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E6 




No 



The directory service verifies that the digital signature 
on the certificate matches the internally stored public key 
of the certificate issuer 



90 




NO 



The directory service verifies that the certificate is still currently 
valid by checking the internally stored certificiate status, or optionally 
against an internally stored Certify Revocation List 



94 




No 



The directory cross references the client certificate, the server 
certificate, and the communications context in crder to retrieve an 
internally stored Access Control Rule to apply to the client connection 



Verification component returns 
from j an Access Rule for the Client 
RG. 5 ; to Server Session to block 76 
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Yes 




No 



Return: 

Connection Denied 
or Deferred 



Fig.6B 
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Fig. 7 



Verification_Descriptor 


::= SEQUENCE! 


Clientidentity 


Certificate, 


ContextDescriptor 


Context, 


Server identity 


Certificate } 



Fig. 8 



Context ::= SEQUENCE { 
version 
time 
protocol 
parameters 



Version 



[0]Version DEFAULT 1996, 
UTCTime, 

OBJECT IDENTIFIER 
ANY DEFINED BY protocol 
OPTIONAL) 
::= INTEGER ( 1996(0) } 



Fig. 9 



IssuerName = Verification_Descriptor->Clientidentity->lssuer 
IssuerPublicKey = ::= SEQUENCE { 

algorithm Algorithmidentifier 

Key BIT STRING) 

Algorithmidentifier ::= SEQUENCE { 

algorithm OBJECT IDENTIFIER ' 

parameters ANY DEFINED BY algorithm 
OPTIONAL) 



Fig. 10 



Clientidentity ::= SIGNED SEQUENCE { 
}" 

IssuerPublicKey = ::= SEQUENCE { 

algorithm Algorithmidentifier 
Key BIT STRING) 

Algorithmidentifier ::= SEQUENCE { 

algorithm OBJECT IDENTIFIER 

parameters ANY DEFINED BY algorithm 
OPTIONAL) 
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FlQ. 1 1 Clientidentity ::= Certificate 

CertificateRevocationList ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX CertificateList 
AuthorityRevocationList ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX CertificateList 
CertificateList ::= SIGNED SEQUENCE! 

signature Algorithmidentifier, 
issuer Name, 
lastUpdate UTCTime, 
revokedCertificates 

SIGNED SEQUENCE OF SEQUENCE! 
signature Algorithmidentifier, 
issuer Name, CertificateSerialNumber subject, 
revocationDate UTCTime} 
OPTIONAL} 



FiO. 12 ACL = Refrieve.ACL from Internal Database (Clientidentity, 
^ ContextDescriptor, Serveridentity) 



Fig. 13 



ACL.Rule ::= SEQUENCE! 

towhat OBJECT IDENTIFIER, 

towhat_parameters ANY DEFINED BY towhat 
OPTIONAL 

bywhat OBJECT IDENTIFIER, 

bywhat_parameters ANY DEFINED BY bywhat 

OPTIONAL 
access INTEGER} 
Version ::= INTEGER! 1996(0) } 
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(57) In an exemplary embodiment, the server re- 
ceives the client's Distinguishing Name (DIM), and then 
searches its directory for identification information and 
access control rights for this specific context. The server 
can act as a stand-alone server or in conjunction with 
other directory services on the network. A client must 
have a verifiable identity in order for secure communi- 
cations to continue. A client's identity can be said to be 
fully verifiable if the server has access to the directory 
service that maintains that client's DN. The client re- 
ceives the server's DN t and the client can then deter- 
mine whether or not to accept a response to a request 
for information (i.e., trust the response). The client de- 
termines the identity of the server using some directory 
service (the client can act stand-alone or as a client of 
other directory servers). A server is fully verifiable if the 
client can identify the directory service that maintains 
the server's DN. In both cases, determining identity is 
predicated on being able to identify a directory service. 
Since servers and clients are issued identities (DN's) 
from some directory service before they participate in 
secure communications, they are able to at least identify 
their "home" directory service. Their "home" directory 
service communicates with other directory services, 
each "serving" their lists of electronic identities to each 
other using secure directory services. In this manner, a 



client or server can verify the peer identity of a secure 
communicator by relying on the trusted "home" directory 
service. Public Key certificates, certificate revocation 
lists, pending certificate requests, Certification Authority 
policy, and other information is stored in the directory 
server. Access to the directory server is through secure 
communications; this maintains the integrity and privacy 
of the information. 
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